Computers are machines that include various devices, whether they be included internally in a computer case, attached in a card cage, or attached externally. In general, application programs may access devices by communicating with device drivers in an operating system. Each kind of device of a plurality of a devices which may be coupled to a computer require a separate device driver. For an application program to communicate with each of the plurality of devices, the application program must include specialized software that allows the application to communicate with each of the plurality of kinds of devices and maintain information concerning the communications with each of the kinds of devices.
FIG. 1 (Prior Art) illustrates a generalized conceptual architecture of prior art communication between application programs and devices in a computer system. Application programs 110 in user space 102 may communicate with various drivers 150 in an operating system kernel that exists in kernel space 104 to access a plurality of devices 160 at hardware level 106. To configure the collection of devices so that they function as desired within a system, an application program 110 accesses and controls the devices 160 by communicating with the appropriate device drivers 150. A drawback of this approach is that since the control requests are sent directly to the individual devices by the application program, the control requests have to be device specific. This hinders the application program from being device independent, as the application program must have the capability to communicate which each of the various devices it wishes to control. For example, for Application A to communicate with devices A, B and C, Application A must format three separate messages according to the requirements of the three different device drivers. As such, Application A must send three separate messages to each of the drivers as shown by lines 120.
In some systems, each kind of device performs a unique function that may also be related to the function of one or more other devices. For example, a state change of one device may trigger an action on one or more other devices. This may result in one driver communicating with one or more other drivers, as shown by inter-driver communication 130. Although direct communication between devices is fast, such direct communication prevents a system from being designed and maintained modularly as each device is required to have knowledge of other related devices. That is, each device driver must know how to communicate with each of the other device drivers.
When, for example, functionality enhancements require the replacement or upgrade of a device, the replacement will require not only the modification or replacement of the device's driver, but also modification of control applications and/or other device drivers that rely on software features and control points of the device. That is, when a device is replaced or upgraded, each of the other devices and application programs that access the device must also be updated so as to be able to communicate with the replaced or upgraded device.
In many embedded computer systems, before executing a user-level request on a device, the application program is required to know the state of all related devices. This results in costly overhead in an embedded system, as each communication to a desired device may require multiple preliminary status requests of other related devices. In addition, when building a redundant device model, each device via its driver may be required to have intricate knowledge of related devices. As already discussed, this increases overhead due to the inter-device communication required. Moreover, hardware and software upgrades are difficult as they cause the re-writing of the device drivers of related devices.
In some systems, a request from an application program to device A may cause device A to generate another request to device B, which in turn may generate a further request to device C. If one of the nested requests fail, the operation needs to be rolled back and restarted. This requires drivers to keep complicated information about the states of other devices. Handling failures in this type of nested request introduces great complexity in the drivers resulting from the dependency among devices.
In some systems, concurrent requests from multiple controlling application programs cannot be easily serialized and may lead to inconsistent states. For example, if Application A sends device-specific requests R1, R2, R3 and R4, and Application B sends device-specific requests S1 and S2, because of the scheduling mechanisms of the operating system, the requests may be received by the devices in an interleaved fashion such as, R1, S1, R2, S2, R3, R4. This may cause unintended results and may waste resources by causing errors that result in a roll back and retry.
When inter-device communication is needed in embedded systems, one drawback of allowing inter-device communication is that if one application's request to a driver is blocked due to the driver waiting for an I/O operation, a second request to the same device from another application may fail or block. In this circumstance, software may be added to each and every driver to return a “busy” indication to the second application. However, adding this software to each driver is burdensome and costly.